…Sync Labels" workflows

Starting from version 3.2.0 of the "actions/upload-artifact" action, "hidden" files are not uploaded by default. The
action considers a file "hidden" if any component of the path starts with `.`.

The "download" job of the "Sync Labels" workflow downloads each of the shared label configuration files from and uploads
them to GitHub Actions workflow artifacts for use by the subsequent job. Since the names of the configuration files
don't start with `.` and they aren't located in a subfolder that starts with `.`, we would not expect that this job
could be impacted by the new hidden file handling behavior. However, it was impacted after all, under certain
conditions. Previously, wildcard patterns were used in the `path` input of the job's "actions/upload-artifact" action
step. It turns out that in the case of wildcards, the entire absolute path to the file is considered in the
determination of whether it is "hidden". The "workspace" in which the workflow's steps are performed is under a path
that includes the repository name. So if the repository name starts with a `.` (e.g., `.github`), then the
"actions/upload-artifact" action step failed spuriously:

```
Run actions/upload-artifact@v3
Error: No files were found with the provided path: *.yaml
*.yml. No artifacts will be uploaded.
```

Although this could be fixed by setting the "actions/upload-artifact" action's `include-hidden-files` input to `true`,
it actually doesn't make sense to use a wildcard in the `path` input when the name of the single file is already
available (the wildcard approach is a vestigial remnant of a previous version of the workflow that downloaded all
configuration files in a single job, before it was changed to using a job matrix). By changing the `path` input value to
the file's explicit relative path, it is ensured that the file will never be treated as "hidden", regardless of the
repository name.